Customers are increasingly requesting the capability to initiate and control internal applications, in particular order entry, scheduling and customer care functionality, via a functionally rich set of API's (Application Programming Interfaces). An application program interface is the specific method prescribed by a computer operating system or by an application program by which a programmer writing an application program can make requests of the operating system or another application.
The clients wish to be able to integrate long-standing internal applications with other third party products that either provide functionality not provided by the internal application or provide functionality in a more flexible way than similar functionality included in the internal application.
Other important requirements include the ability to scale up to a high volume of transactions in a controlled way and for the API access method to use emerging industry standards, specifically XML.
Internal applications today do offer some API capability. Certain internal application functions can be initiated and controlled using well-defined programmatic interfaces, but these interfaces are constrained in the amount of access that is offered to the rich functionality inherent in the internal application.
If a customer writes their own APIs, this constitutes an unsupported way of using an internal application and has the potential to compromise the integrity of the internal application's database. Additionally, these API's generally mirror closely existing internal application screen functions, providing access to full internal application functionality and obeying the same validation rules as terminal input. Because of the close coupling to internal application screens, in order to achieve a particular function, e.g. to enter a telephony order, several APIs need to be invoked in the correct sequence—this is known as a ‘stateful’ interface. Also because of the close coupling with internal application screen functions, these API's have very large parameter sets which are liable to change with each internal application release so there is a continuing maintenance load for any programs that use these API's. Finally, certain applications comprise non-reentrant code which poses problems in a multi-user environment.
Therefore, a method and system is required for opening heretofore closed interfaces, allowing external customers to define the functionality exposed through an application's internal/native API, providing a method for developing such exposed functionality in a stateless manner, and providing a bridge to convert non-re-entrant code into re-entrant code.